Software modules such as file system filter drivers may be stacked or otherwise arranged linearly (e.g., chained), and perform their operations in the order in which they are stacked. For example, in the Windows® 2000 operating system, file system filter drivers are stacked into a driver stack where they are able to intercept file system-directed requests and responses to and from a base file system (such as FAT or NTFS). In this manner, the drivers can do things such as scan file data for viruses, enforce disk usage quotas, encrypt data, and perform other similar functions.
While it is often useful to run more than one such filter driver for each file storage volume of a computer system, these filters are written by a number of vendors, and software bugs often result because of interoperability issues between the various filters. Testing has discovered that these bugs sometimes depend on the order in which drivers are loaded and attach in the filter driver stack. At the same time, there are also certain combinations of filters that by their very nature can only work properly when attached in a certain order. For example, to be effective, an antivirus filter (that reads the contents of a file to look for viruses) needs to see the data before the data is scrambled by an encryption filter.
At present, however, file system filter drivers and other similar software modules are not loaded in any particular order, leading to potential problems. Instead, the actual load order depends on a combination of hints provided to a computer administrator/user, as well as variables such as the file system on the boot volume, and even the alphabetical order of the file system names of other installed drivers. Moreover, there is no guarantee that drivers attach in a particular order even if they are loaded in a particular order. As a result, many combinations of drivers need to be tested, to ensure their correct operation in normal usage.